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U  Communicating  Sequential  Processes  (CSP)  is  a  paradigm  for  communication 
and  synchronization  among  distributed  processes.  The  alternative  construct  is  a 
key  feature  of  CSP  that  allows  nondeterministic  selection  of  one  among  several 
possible  communicants.  A  generalized  version  of  Hoare’s  original  alternative 
construct  that  allows  output  commands  to  be  included  in  guards  has  been 
proposed.  Previous  algorithms  for  this  construct  assume  a  message  passing 
architecture  and  are  not  appropriate  for  multiprocessor  systems  that  feature 
shared  memory.  This  caper  describes  a  distributed  algorithm  for  the  generalized 
alternative  construct  that  exploits  the  capabilities  of  a  parallel  computer  with 
shared  memory.  A  correctness  proof  of  the  proposed  algorithm  is  presented  to 
show  that  the  algorithm  conforms  to  some  satefy  and  liveness  criteria.  Exten¬ 
sions  to  allow  termination  of  processes  and  to  ensure  fairness  in  guard  selection 
are  also  given. 


s 

KEY  WORDS:  Communicating  sequential  processes;  alternative  operation; 
shared  memory  multiprocessor;  parallel  processing. 


1.  INTRODUCTION 

Communicating  Sequential  Processes  (CSP)  is  a  well  known  paradigm  for 
communication  and  synchronization  of  a  parallel  computation.' *'2'  A  CSP 
program  consists  of  a  collection  of  processes  Px,  P2,.~,  P n  that  interact  by 
exchanging  messages.  These  message  passing  primitives,  called  input  and 
output  commands,  are  synchronous — a  process  attempting  to  output 
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(input)  a  message  to  (from)  another  process  must  wait  until  the  second 
process  has  executed  the  corresponding  input  (output)  primitive. 

An  important  feature  of  CSP  is  the  alternative  construct  which  is 
based  on  Dijkstra’s  guarded  command.13’  This  construct  enables  a  process 
of  nondeterministically  select  one  communicant  among  many.  Each  alter¬ 
native  operation  specifies  a  list  of  guards.  Each  guard  has  a  set  of  actions 
associated  with  it  that  cannot  be  executed  until  the  value  of  the 
corresponding  guard  becomes  True.  Each  guard  consists  of  a  sequence  of 
Boolean  expressions  and  an  optional  input  command  (output  guards  were 
not  allowed  in  the  original  specification  of  csp).  A  guard  is  said  to  be 
enabled  if  each  of  the  Boolean  expressions  preceding  the  input  command 
evaluates  to  True.  The  value  of  a  guard  is  True  if  the  guard  is  enabled  and 
its  input  action  has  successfully  completed. 

Implementation  of  the  alternative  construct  on  a  multiple  processor 
computer  has  been  the  subject  of  much  research.'4  111  It  has  been  argued 
that  the  exclusion  of  output  guards  in  the  original  definition  of  CSP  is  too 
restrictive  and  can  degrade  performance.'6 101  A  generalized  alternative  con¬ 
struct  that  allows  output  guards  has  since  been  proposed,  and  algorithms 
to  implement  it  have  been  developed.'4  7’  However,  all  of  the  algorithms 
reported  thus  far  assume  a  message-based  computer  architecture;  no  shared 
memory  is  assumed.  The  principal  contribution  of  this  paper  is  to  present 
an  algorithm  for  implementing  the  generalized  alternative  construct  on  a 
shared  memory  multiprocessor  and  to  prove  its  correctness.  To  the 
authors’  knowledge,  no  such  algorithm  has  previously  been  reported. 

CSP  does  not  assume  shared  memory  between  constituent  processes, 
so  one  might  ask  why  implementation  on  a  shared  memory  machine  is  an 
issue.  Implementation  of  CSP  on  a  shared  memory  architecture  is  an 
important  question  for  several  reasons: 

•  CSP  has  clean  semantics  that  simplify  proving  the  correctness  of 
programs.  It  is  a  worthwhile  programming  paradigm  in  its  own 
right,  independent  of  the  underlying  machine  architecture. 

•  The  message  passing  paradigm  is  a  natural  means  of  expressing 
programs  in  many  application  areas  that  are  well  suited  for  shared 
memory  machines.  For  example,  distributed  discrete  event 
simulation  algorithms  are  usually  described  in  terms  of  message 
passing  paradigms,"213’  and  implementations  on  shared  memory 
architectures  have  been  described."4’  Similarly,  message  passing  is 
used  extensively  in  object-oriented  programming. 

•  Shared  memory  machines  are  widely  available.  Multiprocessors 
such  as  the  BBN  Butterfly™  [see  Ref.  15]  and  Sequent  Balance™ 
are  available  from  the  commercial  sector,  and  numerous  shared 
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memory  research  machines  such  as  IBM’s  RP3  [see  Ref.  16]  and 
the  University  of  Illinois’s  Cedar  [see  Ref.  17]  have  also  been 
developed. 

•  Shared  memory  architectures  provide  fast  interprocessor  com¬ 
munications.  A  complete  interconnection  among  processors  is 
provided,  avoiding  costly  store-and-forward  communication 
software  in  message-based  architectures  such  as  the  Intel  iPSC™ 
[see  Ref.  18].  At  present,  parallel  processors  using  shared  memory 
are  more  appropriate  for  applications  requiring  frequent  com¬ 
munication  among  the  constituent  processes. 

Although  one  can  clearly  “retrofit”  any  message-based  algorithm  to  a 
shared  memory  architecture  by  building  a  suitable  interface,  this  will  often 
lead  to  an  inappropriate  and  awkward  implementation.  Existing  message- 
based  algorithms  for  the  generalized  alternative  construct  are  not 
appropriate  for  a  shared  memory  machine  because  ( 1 )  they  do  not  exploit 
the  facilities  afforded  by  shared  memory,  leading  to  an  inefficient 
implementation;  and  (2)  they  require  additional  “system”  processes  to 
respond  to  incoming  messages  (e.g.,  requests  for  rendezvous)  resulting  in 
unnecessary  context  switching  overhead.  We  will  describe  an  algorithm 
for  the  generalized  CSP  alternative  construct  that  exploits  the  facilities 
afforded  by  shared  memory  and  avoids  the  aforementioned  system 
processes. 

The  algorithm  is  fully  distributed  and  does  not  rely  on  any  centralized 
controller.  The  notion  of  total  ordering  among  processes  [Ref.  6]  is  used  to 
prevent  deadlocks,  but  is  applied  dynamically  on  transactions  (defined 
later)  rather  than  statically  as  originally  proposed.  The  status  of  a  remote 
process  can  be  interrogated  directly,  in  contrast  to  the  message-based 
algorithms  where  message  handshake  and  context  switching  overheads 
reduce  the  efficiency  of  the  implementation.  However,  because  processes  in 
the  proposed  algorithm  concurrently  access  shared  data,  great  care  must  be 
taken  to  avoid  race  conditions.  An  “abort-and-retry”  protocol  is  used  to 
avoid  certain  race  conditions,  and  a  proof  is  also  included  to  verify  that  the 
algorithm  operates  correctly  according  to  safety  and  liveness  criteria."9’ 
Modifications  are  also  suggested  to  achieve  fairness.120’ 

The  remainder  of  this  paper  is  organized  as  follows.  The  semantics  of 
the  generalized  alternative  construct  are  discussed  first,  followed  by  a 
description  of  the  assumed  machine  architecture.  The  proposed  algorithm 
and  a  discussion  of  its  operation  is  then  presented.  Other  important  issues 
related  to  the  algorithm  are  then  discussed,  and  an  extension  to  handle 
termination  of  processes  is  described.  We  conclude  the  paper  with  a  proof 
of  the  correctness  of  the  algorithm  followed  by  a  discussion  of  fairness 
issues. 
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2.  THE  ALTERNATIVE  CONSTRUCT 

A  guard  of  the  alternative  construct  can  appear  in  one  of  two  possible 
forms.  The  first,  called  the  pure  Boolean  form,  contains  no  I/O  command. 
For  example,  in 

(x  =  1  and  _y>5)-*z:=z»3 

the  predicate  to  the  left  of  the  *-»’  operator  is  a  pure  Boolean  guard.  The 
second  form,  called  the  I/O  guard  form,  contains  an  I/O  command  as  well 
as  an  (optional)  Boolean  part.  For  example,  in 

P\  lx  —*  z  z  +  1 

the  input  guard  P,  lx  requests  input  from  process  P, .  The  received  data  is 
assigned  to  the  variable  x.  Guards  such  as  this  which  do  not  contain  a 
Boolean  part  are  referred  to  as  pure  I/O  guards.  In  effect,  the  boolean  part 
is  the  constant  True.  An  I/O  guard  is  said  to  be  enabled  if  the  Boolean  part 
is  True,  so  a  pure  I/O  guard  is  permanently  enabled. 

Consider  the  following  alternative  construct: 

[G|(ie  PB)  S,  □  Gji  jz/0)~+  S/] 

Where  PB  stands  for  the  set  of  indices  of  all  of  the  pure  boolean  guards 
and  IO  the  set  of  indices  of  all  of  the  I/O  guards.  Whenever  this  alternative 
construct  is  executed,  exactly  one  guard  is  selected  and  the  corresponding 
action  (S’,  or  S,)  is  executed.  The  selection  is  made  according  to  the 
availability  of  the  guards.  For  pure  Boolean  guards,  the  guard  is  said  to  be 
available  if  it  is  enabled,  i.e.,  if  the  Boolean  part  evaluates  to  True.  For  I/O 
guards,  the  guard  is  available  if  it  is  enabled  and  the  process  associated 
with  the  guard  is  also  ready  to  communicate  using  the  complementary  I/O 
command.  Because  we  assume  I/O  commands  only  appear  in  guards  of 
alternative  operations,  this  implies  the  remote  process  is  executing  an  alter¬ 
native  operation  in  which  the  corresponding  I/O  operation  is  part  of  an 
enabled  guard.  If  more  than  one  guard  is  available,  one  is  chosen 
arbitrarily.  The  application  program  cannot  control  this  selection. 

Pure  Boolean  guards  can  be  resolved  without  any  interaction  with 
other  processes.  Therefore,  to  simplify  the  discussion  which  follows,  we  will 
restrict  attention  to  the  resolution  of  I/O  guards. 

3.  THE  MACHINE  ARCHITECTURE 

The  machine  is  assumed  to  be  a  shared  memory  multiprocessor.  The 
algorithm  is  well  suited  for  machines  such  as  BBN's  Butterfly  or  Sequent's 
Balance,  among  others.  Several  primitive  are  used  in  the  algorithm. 
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None  are  unusual  in  a  multiprocessor  environment,  and  all  can  be  easily 
constructed  using  a  test-and-set  and  standard  scheduling  primitives. 

The  CSP  program  contains  processes  Pt,  P2,...,  PN.  Process  P ,  is 
assigned  the  unique  process  ID  i  to  distinguish  it  from  others. 

We  will  assume  the  following: 

•  Communications  are  reliable.  An  error  free  communications 
mechanism  exists  so  that  two  distinct  processes  can  communicate 
by  exchanging  a  message.  In  particular,  Send)M,  R)  and  Recv(R): 
Message  provide  the  same  semantics  as  CSP’s  output  and  input 
commands,  respectively.  M  is  the  message  which  is  transmitted  and 
R  is  the  ID  of  the  remote  process  with  which  communications  is  to 
take  place.  Recv  returns  the  received  message  (of  type  Message).  In 
accordance  with  CSP  semantics,  we  assume  the  process  invoking 
the  primitive  blocks  until  process  PR  executes  the  complementary 
I/O  primitive. 

•  Read  and  write  accesses  to  shared  memory  are  atomic,  as  is 
normally  the  case  with  a  shared  memory  multiprocessor. 
Atomic Add(X):  INTEGER  atomically  increments  the  integer 
variable  X  and  returns  the  original  value  of  X. 

•  WaitForSignal  and  Signal  primitives  are  available  to  block  and 
unblock  the  process,  respectively.  A  signal  contains  a  single,  user 
defined  integer  value.  Wait  For  Signal) ):  INTEGER  causes  the 
process  invoking  the  primitive  to  block  until  a  signal  becomes 
available  to  it  from  any  other  process  and  returns  the  integer  value 
stored  within  the  signal.  Signal(R,  i )  sends  a  signal  containing 
integer  i  to  process  PR.  The  Signal  primitive  wakes  up  the  signaled 
process  if  it  is  block  on  WaitForSignal.  Otherwise,  the  signal 
remains  in  effect  until  PR  executes  a  WaitForSignal  primitive.  If  a 
second  signal  is  sent  to  PR  before  the  first  is  absorbed  by  a  call  to 
WaitForSignal ,  the  first  signal  is  discarded. 

•  Lock  and  Unlock  primtives  provide  exclusive  access  to  shared  data 
structures.  Lock(L)  will  block  until  the  lock  L  becomes  zero,  at 
which  time  L  is  set  to  one.  The  “test-and-set”  operation  must  be 
atomic.  Unlock(L)  sets  the  lock  L  to  zero.  Further,  we  assume  the 
Lock  primitive  is  fair,  i.e.,  if  a  process  is  blocked  while  attempting 
to  obtain  a  lock,  it  does  not  remain  blocked  an  unbounded 
amount  of  time  unless  the  lock  is  not  unlocked  for  an  unbounded 
amount  of  time. 

It  is  assumed  that  all  input  and  output  commands  occur  within  guards 
of  the  alternative  construct.  Simple  CSP  input  and  output  primitives  are 
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special  cases  of  the  alternative  construct.  Simple  CSP  input  and  output 
primitives  are  special  cases  of  the  alternative  construct.  We  also  assume 
that  the  variables  used  in  the  alternative  algorithm  are  not  modified  by 
processes  except  as  indicated  in  the  algorithm.  Finally,  it  is  assumed  that 
processes  do  not  terminate.  The  algorithm  can  be  extended  to  handle 
termination,  as  will  be  discussed  later. 

4.  THE  ALTERNATIVE  ALGORITHM 

Each  invocation  of  an  alternative  operation  is  referred  to  as  a  trans¬ 
action.  A  transaction  begins  when  an  alternative  operation  is  initiated  and 
ends  when  a  successful  communication  has  been  completed.  A  process  will 
usually  engage  in  many  transactions  during  its  lifetime.  A  total  ordering  is 
imposed  among  all  transactions  entered  by  all  processes  of  a  given  CSP 
program.  A  unique  sequence  number,  referred  to  here  as  a  transaction  ID , 
is  associated  with  each  transaction. 

Two  processes,  each  of  which  initiates  an  alternative  operation  that 
results  in  a  communication  between  them,  are  said  to  rendezvous.  More 
precise  definitions  of  rendezvous  and  other  terminology  introduced  in  this 
section  will  be  presented  later.  Each  rendezvous  always  involves  exactly 
two  distinct  processes.  In  a  typical  rendezvous,  the  first  process  to  enter  the 
alternative  will  block,  waiting  for  a  signal  from  the  second.  When  the 
second  process  enters  the  alternative,  it  will  commit  to  the  first  in  order  to 
obtain  “permission”  to  rendezvous;  the  “committing”  process  will  then 
signal  and  exchange  a  message  with  the  blocked  process,  and  both  will 
complete  their  respective  alternative  operations. 

A  commit  operation  is,  in  effect,  a  request  for  rendezvous.  It  will  be 
shown  that  a  rendezvous  will  occur  only  after  a  successful  commit 
operation  has  taken  place,  and  every  successful  commit  results  in  a  rendez¬ 
vous.  A  process  will  not  attempt  to  commit  until  it  has  determined  that  the 
process  with  which  it  is  committing  is  a  suitable  candidate  for  rendezvous, 
i.e.,  each  lists  the  other  in  their  respective  guard  lists,  and  the  two  processes 
are  not  both  trying  to  execute  the  same  I/O  operation  ( Send  or  Recv).  The 
commit  operation  resolves  conflicts  when  two  different  processes  attempt  to 
simultaneously  rendezvous  with  a  third.  The  algorithm  uses  an  “abort 
and  retry”  mechanism  to  avoid  race  conditions  when  two  potential 
communicants  simultaneously  enter  the  alternative  command. 

4.1 .  Process  States 

Each  process  can  be  in  one  of  the  following  states: 

•  WAITING.  The  process  is  blocked  on  a  WaitForSignal  operation, 
waiting  for  another  process  to  rendezvous  with  it. 
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•  ALT.  The  process  has  begun  an  alternative  operation,  and  is 
scanning  through  its  list  of  guards  to  find  a  process  with  which  it 
can  rendezvous. 

•  SLEEPING.  The  process  was  forced  to  abort  an  alternative 
operation.  Each  time  the  process  aborts,  it  goes  to  sleep  for  some 
time  before  retrying.  While  blocked  in  this  way,  the  process  is  in 
the  Sleeping  state.  This  state  differs  from  the  Waiting  state 
because  a  process  may  remain  in  the  latter  for  an  unbounded 
amount  of  time. 

•  RUNNING.  The  process  is  executing  user  or  system  code  not 
related  to  the  alternative  operation.  The  process  is  in  the  Running 
state  if  it  is  not  in  any  of  the  other  states  listed  above.  Once  the 
process  initiates  an  alternative  operation,  it  can  only  be  in  the 
Waiting,  Alt,  or  Sleeping  state  until  the  alternative  operation 
completes  with  a  rendezvous. 

It  is  possible  to  combine  the  Running  and  Sleeping  states  into  a  single 
state.  Two  states  are  used  to  simplify  the  description  of  the  algorithm  and 
its  proof. 

A  state  transition  diagram  for  each  process  is  shown  in  Fig.  1.  Initially, 
a  process  is  in  the  Running  state.  Once  the  process  initiates  an  alternative 
operation,  it  enters  the  Alt  state.  If  the  process  is  forced  to  abort  the  alter¬ 
native  it  switches  to  the  Sleeping  state,  and  returns  to  the  Alt  state  when 
it  retries.  If  the  process  is  able  to  commit  and  rendezvous  with  another 
process,  it  returns  to  the  Running  state.  Otherwise,  the  process  moves  to 
the  Waiting  state  until  some  other  process  commits  to  it,  at  which  time  it 
rendezvous  and  returns  to  the  Running  state. 

The  Alt  and  Sleeping  states  should  be  viewed  as  “transitory”  states 
through  which  a  process  passes  while  trying  to  commit  or  move  into  the 
Waiting  state.  It  will  be  shown  that  a  process  cannot  remain  in  either  the 
Alt  or  the  Sleeping  state  for  an  unbounded  amount  of  time  on  a  single 
transaction. 


4.2.  Shared  Variables 

Each  process  Pj  maintains  a  number  of  variables  that  may  be 
examined,  and  in  some  cases  modified,  by  other  processes: 

•  AltListj  lists  the  guards  associated  with  the  last  alternative 
operation  initiated  by  P}  that  caused  P,  to  enter  the  Waiting  state. 

•  AltLockj  is  a  lock  used  to  control  access  to  AltListj.  It  is  initialized 
to  0  (unlocked). 
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•  State j  holds  the  current  state  of  Pr  It  may  be  set  to  Waiting,  Alt, 
Sleeping,  or  Running,  and  is  initialized  to  Running. 

•  WakeUpj  is  initialized  to  1  and  is  set  to  zero  by  Pt  whenever  it 
enters  the  Waiting  state.  It  is  incremented  (atomically)  by 
processes  trying  to  commit  to  Pt.  This  variable  prevents  two 
processes  from  both  successfully  committing  to  a  third  on  a  single 
transaction. 

There  is  also  one  system  wide  global  variable  used  by  the  algorithm: 

•  NextTransID  is  initialized  to  zero  and  is  incremented  each  time  a 
process  initiates  an  alternative  operation.  This  variable  ensures  a 
unique  transaction  ID  can  be  generated  for  each  instance  of  an 
alternative  operation. 

Use  of  a  global  variable  to  generate  unique  transaction  IDs  is  not 
strictly  necessary.  It  is  possible  to  generate  unique  transaction  IDs  that 
conform  to  the  requirements  of  the  algorithm  without  use  of  any  shared 
variables.  This  will  be  discussed  later. 

One  procedure  merits  special  attention.  Cheek AndCommit(m,  gt): 
INTEGER  is  called  by  process  P,  (/  denotes  the  local  process)  to  check  that 
“valid”  communications  can  take  place  between  P,  using  guard  g,  and  Pm 
(m  denotes  the  remote  process).  If  so,  P,  attempts  to  commit  to  Pm.  If 
successful.  Check AndCommit  returns  a  positive  integer  indicating  the 
corresponding  guard  in  the  remote  process  Pm.  Otherwise.  Check AndCom- 


Fig.  1.  State  diagram  of  each  process. 
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mit  returns  a  nonpositive  integer,  denoted  by  the  constant  Failed.  This 
procedure  is  shown  in  Fig.  2. 

Check  AndCommit  uses  a  procedure  CheckGuard{  Alt  List  g,): 
INTEGER  that  scans  the  remote  alternative  list  AltListm  looking  for  a 
matching  and  compatible  guard  gj  to  the  local  guard  g,.  By  matching  we 
mean  gj  contains  an  I/O  operation  with  P,.  By  compatible  we  mean  g,  and 
gj  do  not  both  contain  input  (output)  commands.  ChechGuard  returns  an 
integer  j  that  denotes  the  number  of  a  matching  and  compatible  guard  if 
one  was  found,  and  Failed  otherwise.  If  such  a  guard  is  found,  P ,  attempts 
to  commit  to  Pm  by  testing  if  WakeUp  m  is  zero,  and  if  so,  incrementing  it. 
An  ordinary  addition  is  used  rather  than  the  AtomicAdd  primitive  to 
increment  WakeUpm  because  AltLockm  guarantees  atomicity.  If  P,  is 
the  first  process  to  commit  to  Pm,  i.e.,  if  WakeUpm  was  previously  zero, 
then  P,  successfully  commits,  CheckAndCommit  returns  the  number  of 
the  corresponding  guard,  and  rendezvous  is  imminent.  Otherwise, 
CheckAndCommit  returns  Failed.  AltLockm  ensures  serial  access  to 
Alt  List  m.  As  will  be  demonstrated  later,  it  is  crucial  that  this  lock  is  not 
released  until  after  the  commit  operation  is  attempted  (if  it  is  attempted)  in 
order  to  avoid  race  conditions.  This  would  be  the  case  even  if  an 
AtomicAdd  operation  were  used  to  increment  the  WakeUp  variable. 

/•  a  is  tha  remote  process  *1 

PROCEDURE  CheckAndCoamit(m,&) :  INTEGER; 

VAR 

INTEGER  GuardMumber ;  /*  number  of  matching  guard  */ 

BEGIN 

Lock(AltLocka) ; 

/*  check  guard  matches  and  is  compatible  */ 

GuardNumbar  : *  CheckGuard( Alt List.,  gj)  ; 

IF  (GuardNumbar  -  FAILED)  THEN 

Unlock(AltLockB) ; 

RETURN  (FAILED); 

/*  try  to  commit  */ 

ELSEIF  (MakeUp.  -  0)  THEN 

WakeUp,  ■  WakeUp.  +  1 ; 

Unlock(AltLock.) ; 

RETURN  (GuardNumbar) ; 

ELSE 

Unlock(AltLock.) ; 

RETURN  (FAILED); 

END; 

END  CheckAndCommit; 

Fig.  2.  Procedure  to  check  that  a  potential  communication  is  valid  and,  if  so, 
to  commit.  The  CheckGuard  function  returns  the  number  of  a  matching  (and 
compatible)  remote  guard  or  returns  Failed  if  none  was  found. 
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4.3.  Other  Notation 

For  notational  convenience,  other  variables  and  predefined  functions 
are  defined  that  are  used  in  the  algorithm.  These  include: 

•  TransID,  is  a  variable  that  contains  the  ID  of  the  current  trans¬ 
action  in  which  process  Pt  is  engaged. 

•  CommunicantIDfg,)  is  a  function  that  returns  the  ID  of  the 
process  listed  in  the  I/O  command  portion  of  guard  g(. 

•  Communicatefg,)  executes  the  I/O  command  in  guard  g,. 

4.4.  Description  of  the  Algorithm 

The  alternative  algorithm  is  shown  in  Figs.  3  and  4.  The  Alternative 
procedure  shown  in  Fig.  3  is  a  “front  end”  that  is  responsible  for  retrying 
aborted  attempts.  It  does  not  return  until  a  rendezvous  has  been  completed 
at  which  time  it  returns  an  integer  indicating  the  guard  that  was  eventually 
satisfied.  The  heart  of  the  algorithm  lies  in  the  Try  Alternative  procedure 
shown  in  Fig.  4.  The  parameters  passed  to  this  and  the  Alternative 
procedure  are  n  enabled  I/O  guards  gt,  g2,->g„-  Each  guard  contains 
either  a  single  output  or  a  single  input  primitive. 

The  Alternative  procedure  first  obtains  a  unique  transaction  ID  by 
performing  an  Atomic  Add  operation  on  the  global  NextTransID  variable. 
It  then  attempts  to  rendezvous  by  calling  the  Try  Alternative  procedure. 
TryAlternative  either  returns  the  number  of  the  guard  on  which  a  rendez¬ 
vous  occurred,  or  the  Failed  flag  indicating  the  attempt  must  be  retried. 
The  same  transaction  ID  remains  in  use  despite  one  or  more  failed 


/*  gi  are  enabled  1/0  guards  */ 

PROCEDURE  Alternative^! . gn):  INTEGER; 

VAR 

INTEGER  RetumValue;  /*  indicates  guard  that  rendezvoused  */ 
BEGIN 

/*  1  is  the  local  process  id  */ 

TransIDi  :■  AtomicAdd(NextTransID) ; 

RetumValue  :»  FAILED; 

WHILE  (RetumValue  »  FAILED)  DO 

RetumValue  :»  TryAlternativeCgi ,  ....  g„) ; 

END; 

RETURN  (RetumValue) ; 

END  Alternative; 

Fig.  3.  The  “front  end"  procedure.  TryAlternative  returns  the  number  of  the  guard  on  which 
a  rendezvous  took  place  or  Failed  if  it  aborted. 
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attempts.  It  will  be  shown  that  Try  Alternative  cannot  fail  an  unbounded 
number  of  times  within  a  single  transaction.  In  the  discussed  that  follows, 
P,  again  refers  to  the  local  process  and  Pm  to  the  remote  process  with  the 
guard  that  is  being  scanned. 


PROCEDURE  Try Alternative (gi ,  ....  go):  INTEGER; 

VAR 

BOOLEAN  flag; 

INTEGER  GuardMuaber ;  /•  corresponding  guard  of  P.  •/ 

INTEGER  i,  a,  ReaotelD; 

BEGIN 

Statai  :»  ALT; 

/*  look  for  rendezvous  with  a  waiting  process.  */ 

FOR  i:-l  TO  n  DO 

■  :■  ComaunicantlD(gi) ; 
flag  TRUE; 

WHILE  (flag)  DO 

CASE  State.  DO  /*  Tha  remote  process  state.  */ 

RUNNING:  flag  FALSE; 

SLEEPING:  flag  : *  FALSE;  /*  try  next  guard  */ 

HAITI IG:  GuardMuabar  :■  CheckAndCoaait(»,  gi) ; 

IF  (GuardMuabar  -  FAILED)  THEN 

flag  :*  FALSE;  /*  try  next  guard  */ 

ELSE  /*  Hake  up  P.  */ 

State!  :«  HUMMING; 

Signal (a,  GuardMuabar); 

Cosaunicate(gi) ; 

RETURN  (i); 

END; 

ALT:HeaoteID  :»  TransID.; 

IF  (TranelDi  <  ReaotelD)  THEN 

WHILE  ((State.  -  ALT)  AND  (ReaotelD  «  TransID.))  DO  END 
ELSE 

State!  SLEEPING; 

WHILE  ((State.  ■  ALT)  AND  (ResiotelD  *  TransID.))  DO  END 
RETURN  (FAILED);  /*  abort...*/ 

END;  /*  if-then-else  */ 

END;  /*  case  statenent  */ 

END;  /*  while  loop  */ 

END;  /*  for  statement  */ 

/*  couldn’t  find  guard  to  rendezvous  */ 

Lock(AltLocki);  AltListi:«(gi ,  ....  g.);  Unlock(AltLocki); 

WakeUp!  :■  0;  /*  first  to  coaait  gets  rendezvous  */ 

Statei  :*  WAITING;  i  :*  HaitForSignalO ;  State!  RUNNING; 

Comaunicate(gi) ; 

RETURN  (i); 

END  TryAlternative; 

Fig.  4.  The  TryAlternative  procedure  attempts  to  rendezvous. 
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After  setting  the  state  of  the  process  to  Alt,  P,  examines  each  guard 
listed  in  the  alternative  operation  one  after  the  other.  Some  action  is  then 
performed  depending  on  the  state  of  P„. 

If  Pm  is  in  the  Running  state,  P ,  simply  advances  to  the  next  guard.  In 
this  case,  Pm  has  not  yet  entered  a  transaction  and  is  not  yet  ready  to 
rendezvous. 

If  Pm  is  in  the  Sleeping  state,  P,  again  advances  to  the  next  guard.  P, 
advances  because  the  Alternative  procedure  guarantees  that  the  Sleeping 
process  (Pm)  will  eventually  retry  its  alternative  operation.  It  will  be  shown 
later  that  a  process  cannot  remain  in  the  Sleeping  state  for  an  unbounded 
amount  of  time.  If  P,  and  Pm  are  destined  io  eventually  rendezvous  on  this 
transaction,  P,  will  typically  proceed  to  the  Waiting  state,  and  P,n  will 
later  retry,  commit,  and  rendezvous  with  P,. 

If  Pm  is  Waiting,  then  Pm  has  already  reached  the  rendezvous  point 
so  P,  attempts  to  rendezvous.  AltListm  is  examined  to  make  sure  a  valid 
communication  can  take  place,  and  if  so,  P,  attempts  to  commit.  If 
successful,  P,  will  awaken  Pm  (by  sending  a  signal)  and  rendezvous. 
Otherwise,  P,  advances  to  the  next  guard. 

Finally,  if  Pm  is  in  the  Alt  state,  some  spcial  precautions  must  be 
taken  to  avoid  race  conditions.  This  situation  could  result,  for  example, 
when  Pi  and  Pm  initiate  an  alternative  operation  at  approximately  the  same 
time.  The  two  processes  may  or  may  not  be  destined  to  rendezvous, 
however.  In  fact,  Pm’s  alternative  operation  may  not  even  contain  a  guard 
with  P,  as  a  communicant. 

If  P,  sees  Pm  in  the  Alt  state,  P,  will  pause  in  a  busy  wait  loop  until 
Pm  either  changes  to  another  state  or  advances  to  a  new  transaction.  To 
avoid  deadlock  (e.g.,  two  processes  each  waiting  for  the  other  to  leave  the 
Alt  state),  P,  will  first  change  to  the  Sleeping  state  if  its  transaction  ID  is 
larger  than  that  of  P„,’s.  In  this  case.  P,  must  abort  and  retry  the  operation 
after  Pm  changes  state  in  order  to  avoid  race  conditions  (discussed  later,  in 
the  proof  of  Lemma  8 ).  Because  higher  priority  is  given  to  the  process  with 
a  smaller  transaction  ID,  the  priority  of  each  transaction  tends  to  increase 
with  time.  This  is  necessary  to  ensure  liveness  in  the  algorithm. 

Although  the  busy  wait  loop  and  abort  retry  scenario  might  initially 
appear  to  cause  wasted  time  that  could  be  better  spent  pursuing  other 
activities,  it  is  anticipated  that  this  situation  will  arise  infrequently  in  prac¬ 
tice.  Performance  evaluations  using  empirical  techniques  are  currently  in 
progress  to  verify  that  this  is  the  case. 

It  is  interesting  to  note  that  the  state  of  Pm  may  change  immediately 
after  P,  examines  State m.  It  will  be  proven  that  the  algorithm  operates 
correctly  despite  this  apparent  inconsistency.  In  fact,  it  will  be  shown  that 
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the  only  locking  that  must  be  performed  in  the  entire  algorithm  is  that 
associated  with  Alt  Lock. 

If  P,  goes  through  its  entire  guard  list  without  rendezvousing  with 
another  process,  P,  enters  the  Waiting  state  and  calls  WaitForSignal  to 
block  until  another  process  commits  to  it.  Before  calling  WaitForSignal , 
however,  P,  also  sets  AltList,  to  contain  the  current  guard  list  and 
“activates”  Wake  Up,  by  setting  it  to  zero.  After  some  process  later  commits 
to  Ph  a  signal  is  received,  a  communication  takes  place,  and  Try  Alternative 
returns  the  identity  of  the  (local)  guard  that  rendezvoused.  This  infor¬ 
mation  was  sent  to  P ,  in  the  signal  that  awakened  it. 

We  should  emphasize  at  this  point  that  it  is  crucial  that  the  operations 
listed  in  Figs.  2-4,  be  performd  in  exactly  the  order  in  which  they  appear. 
Seemingly  minor  changes  such  as  swapping  the  order  of  the  statements 

WakeUp,  :=0; 

State,  .=  WAITING; 

introduces  a  race  condition  that  invalidates  the  correctness  proof. 

We  note  that  the  Lock  operation  preceding  the  statement  that 
modifies  AltList  must  remain  even  if  modification  can  be  done  atomically. 
The  locking  protocol  in  this  and  the  CheckAndCommit  procedure  are 
carefully  designed  to  avoid  race  conditions.  Finally,  it  is  noteworthy  that 
the  statement  that  sets  WakeUp,  to  zero  need  not  be  executed  while 
AltLock,  is  locked.  The  correctness  proof  only  requires  that  two  processes 
do  not  both  read  a  zero  value  from  WakeUp,  during  a  single  transaction 
of  P,. 


5.  DISCUSSION 

Several  aspects  of  the  alternative  algorithm  merit  further  discussion. 
These  are  discussed  next. 

5.1.  Transaction  IDs 

The  algorithm  uses  dynamically  assigned  transaction  IDs  to  determine 
the  “winner”  when  a  process  finds  another  in  the  Alt  state.  Dynamic  IDs 
are  used  rather  than  static,  process  IDs  to  ensure  liveness.  Intuitively, 
liveness  means  that  two  processes  that  "should”  rendezvous  eventually  will, 
while  safety  means  that  any  rendezvous  that  occurs  is  valid.  The  proposed 
approach  avoids  scenarios  in  which  a  process  is  repeatedly  forced  to  abort 
and  retry  its  alternative  operation  an  unbounded  number  of  times;  this  is 
because  the  priority  of  a  transaction  automatically  increases  with  time  as 
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other  transactions  are  allowed  to  complete  and  new  ones,  with  higher  IDs 
and  correspondingly  lower  priorities,  are  initiated.  Dynamic  transaction 
IDs  guarantee  this  property  while  static  IDs  do  not.  It  is  important  that  a 
new  transaction  ID  is  only  allocated  when  an  alternative  is  first  initiated, 
as  in  done  in  Fig.  3,  and  not  when  an  existing  operation  is  retried. 

One  can  avoid  using  a  global  variable  ( NextTransID )  to  generate 
transaction  IDs  if  contention  is  a  concern.  This  function  can  be  performed 
locally,  within  each  process.  Process  P ,  can  create  a  new,  unique,  trans¬ 
action  ID  by  concatenating  a  local  sequence  number  with  /,  the  unique  ID 
for  the  process.  The  sequence  number  is  incremented  each  time  a  new 
transaction  ID  is  created  by  that  process.  It  is  imperative  that  the  process 
ID  occupy  the  least  significant  portion  of  the  transaction  ID  to  ensure 
liveness,  as  was  discussed  earlier. 

A  second  concern  is  overflow  of  the  NextTransID  variable.  Overflow 
invalidates  the  liveness  property  of  the  algorithm  because  a  transaction’s 
priority  does  not  necessarily  increase  with  time.  Also,  because  transaction 
IDs  cannot  be  guaranteed  to  be  unique  after  overflow  has  occurred,  the 
arbitration  protocol  could  fail  (this  could  be  circumvented  by  appending 
the  process  ID  to  the  least  significant  portion  of  the  transaction  ID, 
however).  In  any  event,  overflow  can  be  easily  avoided  by  using  a  variable 
of  large  precision.  For  example,  a  64  bit  variable  will  not  overflow  with 
1000  processes,  each  initiating  a  new  alternative  construct  every  micro¬ 
second,  in  over  500  years! 

5.2.  Channel  I/O 

In  many  CSP  implementations,  interprocess  communication  is  based 
on  pre-allocated  channels.  Each  channel  is  a  unilateral  link  between  two 
communicating  processes.  The  channel  model  facilitates  modularity, 
reusability,  and  hierarchical  construction  of  programs  because  a  program 
can  be  "constructed”  by  interconnecting  a  group  of  constituent  processes. 
The  algorithm  presented  above  can  be  adapted  to  the  channel  I/O  model 
by  modifying  the  Send  and  Recv  primitives  and  translating  port  identifiers 
to  process  IDs.  The  Check AndCommit  procedure,  for  instance,  must  be 
modified  to  check  for  matching  channels  rather  than  matching  process  IDs. 
These  modifications  are  a  simple  extension  of  the  proposed  algorithm. 

5.3.  Termination 

Termination  is  another  important  issue  facing  real  implementations. 
This  was  not  treated  in  the  previous  discussion  to  simply  the  presentation. 
The  termination  semantics  play  an  important  role  in  CSP  because  it  is  the 
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basis  of  the  termination  of  the  repetitive  command." 1  If  an  alternative 
operation  is  embedded  within  a  repetitive  command  and  no  guard  of  the 
alternative  can  become  true,  e.g.,  because  all  processes  associated  with 
enabled  guards  have  terminated,  the  repetitive  command  terminates.  If  no 
such  repetitive  command  surrounds  the  alternative  operation  and  it  is 
found  that  no  guards  can  become  true,  an  error  results. 

In  the  context  of  the  proposed  algorithm,  it  is  sufficient  that  the  Alter¬ 
native  procedure  determine  when  no  guards  can  become  satisfied  and 
return  an  appropriate  flag  denoting  this  situation.  The  algorithm  can  be 
extended  to  handle  termination  by  adding  a  shared  variable  called 
GuardCount  t  to  each  process  P,  and  a  new  process  state  called  Terminated. 
GuardCount ,  indicates  the  number  of  I/O  guards  on  which  P,  might  poten¬ 
tially  rendezvous  in  the  current  transaction  and  contains  a  meaningful 
value  whenever  P,  is  in  the  Waiting  state.  It  is  equivalent  to  the  number  of 
guards  in  AltListj.  The  GuardCount,  variable  is  used  to  detect  situations  in 
which  P,  cannot  rendezvous  because  ail  of  the  processes  in  its  guards  have 
terminated.  This  is  the  only  case  in  which  the  Alternative  procedure  will 
return  without  rendezvous. 

Whenever  a  process  Pj  terminates,  it  marks  its  state  as  Terminated 
and  then  examines  the  state  of  each  of  its  neighboring  processes,  i.e.,  those 
processes  which  might  communicated  with  P}.  If  P,  finds  another  process 
P,  in  the  Alt  state,  it  executes  a  busy  wait  loop  until  State,  changes.  This  is 
necessary  because  P,  cannot  know  if  P,  saw  P,  had  entered  the  Terminated 
state.  If  Pj  finds  P,  in  the  Waiting  state  and  A  It  List,  contains  a  guard 
listing  Pj  as  a  communicant,  then  Pj  (atomically)  decrements  GuardCount , 
to  indicate  that  one  fewer  guard  is  available  for  rendezvous.  No  further 
action  is  required  unless  the  decrement  operation  causes  GuardCount ,  to 
become  zero.  In  this  case,  the  terminating  process  must  send  P,  a  special 
signal  to  indicate  P/s  alternative  operation  can  never  rendezvous.  Upon 
receiving  this  signal,  the  alternative  operation  in  P,  will  return  a  special  flag 
indicating  the  alternative  operation  completed  without  rendezvous. 

When  looking  for  a  process  with  which  to  rendezvous,  i.e.,  when  scan¬ 
ning  the  status  of  neighboring  processes  in  the  Try  Alternative  procedure, 
an  I/O  guard  corresponding  to  a  terminated  process  is  skipped  in  the 
same  way  processes  in  the  Running  or  Sleeping  state  are  skipped.  Such 
guards  are  excluded  from  Alt  List ,  and  GuardCount,  should  the  process 
fail  to  rendezvous  and  move  into  the  Waiting  state.  If  all  I/O  guards 
correspond  to  terminated  processes,  the  alternative  construct  again  returns 
a  flag  indicating  the  operation  completed  without  rendezvous. 

Finally,  some  precautions  must  be  taken  to  avoid  race  conditions.  The 
mechanism  described  above  to  notify  a  Waiting  process  that  it  cannot  ren¬ 
dezvous  on  any  of  its  guards  bears  some  resemblance  to  the  protocol  used 
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to  commit  to  a  process — the  WakeUp  variable  is  analogous  to  GuardCount 
and  committing  (by  incrementing  WakeUp)  is  analogous  to  decrementing 
GuardCount.  Therefore,  it  is  not  surprising  that  the  precautions  that  are 
necessary  to  avoid  race  conditions  are  similar.  In  particular,  GuardCountt 
must  be  set  before  P,  sets  State ,  to  Waiting  but  after  P,  modifies  Alt  List  ( 
(see  Fig.  4).  Identical  containsts  apply  regarding  the  moment  at  which 
WakeUp  to  set  to  zero.  Finally,  when  Pi  wishes  to  decrement  GuardCount ,, 
the  same  protocol  that  was  used  in  the  CheckAndCommit  procedure  (see 
Fig.  2)  to  lock  AltLocki  must  be  used  to  decrement  GuardCount ,,  i.e., 
AltLockj  must  not  be  released  until  after  the  decrement  operation  has 
completed. 

6.  Proof  of  Correctness 

The  correctness  of  the  algorithm  is  established  by  proving  that  during 
the  (potentially)  infinite  execution  sequence,  all  processes  and  the  interplay 
between  them  maintain  invariant  properties  known  as  safety  and 
liveness.tHn)  As  previously  described,  safety  means  that  any  rendezvous 
which  occurs  is  correct.  For  example,  it  is  not  possible  for  two  processes  to 
rendezvous  which  do  not  each  list  the  other  in  some  guard  of  their  respec¬ 
tive  alternative  lists.  Liveness  ensures  that  two  processes  which  should 
rendezvous  eventually  will,  provided  of  course  each  does  not  first  rendez¬ 
vous  with  some  other  process.  These  terms  are  defined  more  formally  in 
Theorems  2  and  3.  Intuitively,  the  safety  property  ensures  that  nothing 
“bad”  will  happen,  while  liveness  ensures  something  “good”  will  eventually 
happen.  Together  they  guarantee  correct  operation  of  the  algorithm. 

Before  beginning  the  proof,  terminology  that  has  been  used  informally 
until  now  will  be  defined  more  precisely.  These  definitions  are  in  terms  of 
the  alternative  algorithm  shown  in  Figs.  2-4.  It  is  assumed  throughout  that 
the  CSP  program  consists  of  a  collection  of  processes  P,,  P2,...,  PN- 

6.1.  Definitions 

1.  A  process  P ,  is  said  to  enter  a  transaction  Tr  when  P,  calls  the 
Alternative  function.  It  exits  transaction  Tr  when  it  returns  from 
the  function  call.  The  notation  P,(  T,)  should  be  read  “process  P, 
(while  P,  is  in  transaction  Tr)."  It  will  be  clear  from  the  context 
that  this  notation  is  used  that  P,  must  be  in  some  transaction. 
Each  transaction  has  a  unique  ID  associated  with  it  (r  for  trans¬ 
action  Tr)  that  is  used  to  form  a  total  ordering  among  all  trans¬ 
actions.  A  transaction  need  not  terminate.  For  example,  the 
application  program  may  deadlock. 
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2.  A  process  P,  in  transaction  T,  is  said  to  commit  to  process  Pt  if 
P,(Tr)  increments  WakeUpj  from  zero  to  one.  The  algorithm  is 
such  that  every  time  WakeUpj  is  incremented,  a  commit  operation 
takes  place. 

3.  A  transaction  Tr  executed  by  process  P,  is  said  to  rendezvous  with 
transaction  Ts  for  process  Pj  if  either  (a)  P,  is  in  the  Waiting  state 
and  receives  a  signal  from  PJt  or  (b)  P,  signals  Pt  after  committing 
to  Pj.  It  will  be  shown  that  once  a  process  rendezvous,  it  will 
exchange  a  message,  complete  the  current  transaction  and  return 
to  the  Running  state. 

4.  A  signal  sent  by  Pt  to  Pj  is  said  to  be  pending  if  ( 1 )  it  was  sent  but 
has  not  yet  been  received  by  Pt,  or  (2)  it  was  received,  but  has  not 
yet  been  absorbed  by  Pt  through  a  call  to  Wait  For  Signal. 

5.  A  communication  between  P,  and  P}  is  compatible  if  one  process 
wishes  to  send,  and  the  other  wishes  to  receive.  Otherwise,  the 
communication  is  said  to  be  incompatible. 

6.  VAR,(Tr)  denotes  the  value  of  state  variable  VAR  of  process  P, 
during  transaction  Tr.  For  example,  AltList,(Tr )  is  the  alternative 
list  of  Pi  during  transaction  Tr.  If  significant,  the  point  in  time 
during  the  transaction  that  is  referred  to  will  be  stated  explicitly. 

7.  GuardList i(T r)  lists  the  guards  that  are  passed  as  parameters  to 
the  alternative  operation  executed  by  /*,  on  transaction  Tr.  We 
will  take  the  liberty  of  giving  GuardList  a  dual  meaning — it  either 
refers  to  a  list  of  guards  or  a  list  of  processes  that  are  designated  in 
the  I/O  commands  of  these  guards.  The  particular  meaning  that  is 
intended  will  be  clear  from  the  context. 


6.2.  The  Safety  Property 

Lemmas  1-5  and  Theorem  1  state  that  no  race  conditions  arise  that 
might  cause  a  process  to  mistakenly  rendezvous  with  a  second  process  that 
does  not  wish  to  rendezvous  with  the  first.  Theorem  2  subsumes  Theorem  1 
and  ensures  that  the  algorithm  obeys  the  safety  property. 

Lemma  1.  />,(7’,)  signals  Pj  iff  Pt(Tr)  commits  to  Pr 

Proof.  This  follows  immediately  from  examination  of  the  algorithm. 
A  process  only  sends  a  signal  after  it  commits,  and  always  sends  a  signal 
after  it  commits.  | 

Lemma  2.  At  the  beginning  and  at  the  end  of  each  transaction 
entered  by  Pj,  the  following  conditions  must  hold: 
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(a)  No  signals  sent  to  Pj  are  pending. 

(b)  WakeUpj  is  nonzero. 

Proof.  Use  induction  on  k,  the  number  of  transactions  entered  by  Pr 
Consider  the  first  transaction  (&=  1)  executed  by  Pj.  Condition  (b)  must 
be  true  at  the  beginning  of  this  transaction  because  WakeUpj  is  initialized 
to  1  and  is  only  modified  by  Pj  during  a  transaction.  Condition  (a)  is  also 
true  because  no  process  can  send  a  signal  to  P,  until  WakeUpj  is  reset  to  0. 

If  Pj  does  not  reset  WakeUpj  to  0  during  its  first  transaction,  (a)  and 
(b)  are  trivially  true  at  the  end  of  the  transaction.  If  P,  does  reset  WakeUpj 
to  0  during  its  first  transaction,  (a)  and  (b)  are  true  at  the  end  of  the  trans¬ 
action  because  (1)  Pj  resets  WakeUpj  to  0  at  most  once  during  any  trans¬ 
action;  (2)  the  atomicity  of  the  “test-and-increment  WakeUp  ”  operation  in 
the  Check AndCommit  procedure  guarantees  that  at  most  one  process  will 
commit  and  send  a  signal  to  P,  as  a  result  of  WakeUp ,  being  set  to  0;  and 
(3)  Pj  always  calls  WaitForSignal  after  resetting  WakeUpj  to  0,  so  the  only 
signal  that  can  be  sent  to  Pj  must  be  absorbed.  Therefore,  (a)  and  (b)  are 
again  true  at  the  end  of  the  first  alternative  operation  as  well  as  at  the 
beginning. 

Inductive  step :  Assume  lemma  2  is  true  on  the  end  of  the  Lth  trans¬ 
action  entered  by  Pj.  It  is  easy  to  see  that  lemma  2  is  also  true  at  the  begin¬ 
ning  and  end  of  the  k  +  1st  transaction  entered  by  P,  using  arguments 
identical  to  those  presented  before.  | 

Lemma  3.  Two  processes,  P,  and  P,,  cannot  both  commit  to  a 
third  process  Pk  during  a  single  transaction  T,  entered  by  Pk. 

This  lemma  was  actually  proven  as  part  of  the  proof  of  Lemma  2,  but 
we  include  it  as  a  separate  lemma  for  future  reference. 

Lemma  4.  If  P,(Tr)  commits  to  Pr  then  P,  must  have  been  in  the 
Waiting  state  when  P,  committed  to  P,,  and  Pj  must  remain  in  the 
Waiting  state  until  Pj  receives  the  signal  sent  by  P,  that  results  from  this 
commitment. 

Proof.  P,  check  that  P,  is  in  the  Waiting  state  before  trying  to  com¬ 
mit  to  Pj.  Let  us  assume  Pj  is  in  transaction  Ts  when  P,  sees  P,  in  the 
Waiting  state.  Therefore,  it  only  remains  to  be  shown  that  Pj  is  still  in  the 
Waiting  state  in  transaction  Ts  when  P,  commits,  as  well  as  when  the 
signal  is  received. 

Suppose  Pj  completed  Ts  before  P,  committed.  Then,  Pj  must  have 
advanced  to  another  transaction  (T,)  and  reset  WakeUpj  to  0  before  P, 
committed,  or  else  P/s  commit  would  have  failed.  If  P,  e  GuardList^  T, ),  Pj 
would  not  have  been  able  to  scan  past  the  guard  containing  P,  because  P, 
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is  in  the  Alt  state,  so  it  must  be  that  P,$GuardListj(T,).  Then,  it  must  be 
that  ( 1 )  P,  checked  Alt  List y  while  the  list  corresponded  to  some  transaction 
preceding  T,  (or  again,  the  commit  would  have  failed);  (2)  Pj(T,)  modified 
AltListj  and  reset  WakeVpj  to  0;  and  (3)  P,  successfully  committed  to  Pr 
However,  the  CheckAndCommit  operation  guarantees  that  checking  AltList 
(step  1)  and  committing  (step  3)  are  atomic,  so  AltList f  could  not  have 
been  modified  between  these  two  operations.  Therefore,  P,  must  have  still 
been  in  Ts  when  P,  committed. 

Pj  must  also  remain  in  the  Waiting  state  until  the  signal  is  received 
because  Pj  cannot  leave  this  state  until  it  first  receives  a  signal.  By  Lem¬ 
ma  2a,  there  were  no  signals  pending  when  transaction  Ts  began.  By 
Lemma  3  no  process  other  than  P,  will  commit  to  Py  during  this  trans¬ 
action,  so  no  signal  other  than  P/s  are  sent  to,  or  received  by  P,  during  Ts. 
Therefore,  Pj  cannot  unblock  from  the  WaitForSignal  operation  and 
therefore  cannot  change  state  until  receiving  the  signal  sent  by  Pr  | 

The  preceding  lemma  shows  that  arbitrarily  long  delays  may  occur 
from  the  time  P,  observes  that  Py  is  in  the  Waiting  state  until  P/  s  signal 
actually  arrives  at  Pj.  If  the  commit  succeeded,  this  lemma  guarantees  that 
nothing  “interesting”  will  happen  at  Pj  from  the  time  P,  found  it  to  be 
waiting  until  the  signal  was  received.  This  lemma  also  highlights  the 
necessity  of  ensuring  that  checking  the  remote  guard  list  and  committing 
are  implemented  as  an  atomic  operation. 

Lemma  5.  No  signals  are  lost  in  the  alternative  algorithm. 

Proof.  This  follows  immediately  from  the  previous  lemmas.  No 
signals  can  be  sent  to  a  process  while  another  signal  is  pending,  so  none  are 
lost.  | 

Theorem  1.  If  P{Tr)  signals  (rendezvous)  P;,  then  P,  must  be  in 
some  transaction  Ts  both  when  the  signal  is  sent  and  when  it  is  received. 
Further,  Pj(Ts)  rendezvous  P,( Tr). 

Proof.  By  Lemma  4,  Py  must  be  in  a  transaction  when  the  signal  is 
sent  and  when  it  is  received,  and  remain  in  the  Waiting  state  during  this 
period.  By  Lemma  5,  P/s  signal  cannot  be  lost.  By  Lemmas  1,  2a,  and  3, 
this  is  the  signal  received  by  P,  during  transaction  Ts,  eliminating  the 
possibility  of  P,  accepting  another  signal  instead  of  P/s.  Because  P,  always 
executes  WaitForSignal  when  in  the  Waiting  state,  the  signal  from  P,  must 
be  received  and  absorbed,  implying  Py  rendezvous  with  P,.  | 

Theorem  2  (Safety).  If  P,(Tr)  commits  to  Pj(Ts),  then  the  follow¬ 
ing  properties  must  be  true: 
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1.  (Mutual  consent)  P,(Tr)  rendezvous  P,(TS)  and  P,{TS)  rendezvous 
Pt(  Tr ).  In  other  words,  the  two  communicating  parties  agree  each 
is  rendezvousing  with  the  other. 

2.  Pj  €  GuardList ,( T, )  and  P,  e  GuardList j(  Ts ). 

3.  Communications  between  P£Tr)  and  Pj(Ts)  are  compatible. 

4.  P,  and  Pj  will  eventually  communicate,  complete  their  transaction, 
and  return  to  the  Running  state. 

5.  There  does  not  exist  a  third  process  Pk  ( k  i  and  k  #  j)  such  that 
Pk(T,)  rendezvous  with  either  Pt(Tr)  or  Pj(Ts). 

Proof. 

1.  P,(Tr)  commits  to  Pj(Ts),  implying  P,{ T, )  signals  P,(TS) 
(Lemma  1).  This  in  turn  implies  the  mutual  rendezvous  according 
to  Theorem  1. 

2.  The  first  part,  Pt  e  GuardList ,( T,),  is  trivially  true  because  P, 
would  not  have  scanned  P;  were  this  not  the  case.  The  second 
part,  P,  e  GuardList j(  Ts),  must  also  be  true  because  this  condition 
is  checked  by  the  CheckAndCommit  procedure  after  P,  discovers 
Pj  is  in  the  Waiting  state.  According  the  Lemma  4,  Pl  remains  in 
the  Waiting  state  until  it  receives  the  signal  sent  by  P,. 

3.  Compatibility  is  checked  when  P,(  Tr )  checks  that  it  is  in 
Alt  List fT,).  Therefore,  the  proof  of  this  part  is  identical  to  that 
used  in  part  (2). 

4.  Once  rendezvous  occurs  between  P\Tr)  and  P/T,),  each  process 
initiates  a  communication  with  the  other.  Properties  (2)  and  (3) 
and  the  reliability  assumption  regarding  the  communication 
mechanism  guarantee  that  the  communication  succeeds.  Once  this 
occurs,  completion  of  the  alternative  operation  immediately 
follows. 

5.  Suppose  Pk(  T,)  rendezvoused  with  either  P,{  Tr)  or  Pj{  Ts).  Recall  a 
rendezvous  occurs  by  either  sending  or  receiving  a  signal  to  or 
from  another  process,  so  there  are  four  possibilities: 

(a)  Pk(T,)  received  a  signal  from  P,{Tr); 

(b)  Pk(T,)  received  a  signal  from  Pj(Ts); 

(c)  Pk{T,)  sent  a  signal  to  P,(rr);  or 

(d)  Pk(T,)  sent  a  signal  to  Pj{Ts). 

However,  (a)  would  imply  Pf  sent  two  signals  during  a  single 
transaction.  It  is  clear  from  the  algorithm  that  this  cannot  occur, 
(b)  and  (c)  imply  that  either  P,  or  Pj  send  and  receive  a  signal 
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during  a  single  transaction.  Again,  it  is  clear  from  the  algorithm 
that  this  cannot  occur,  (d)  implies  Py  receives  two  signals  during  a 
single  transaction.  This  is  not  possible  because  of  Lemas  3  and  4. 
Therefore,  none  of  these  situations  is  possible.  | 

6.3.  The  Liveness  Property 

The  liveness  property  guarantees  that  no  deadlock  or  livelock 
situations  can  arise  within  the  alternative  algorithm.  Such  situations  can 
only  be  caused  by  an  erroneous  application  program.  Lemmas  6-12  and 
Theorem  3  prove  that  the  liveness  property  is  maintained  by  the  proposed 
algorithm. 

Lemma  6.  A  process  P,  will  never  return  to  the  Running  state 
after  entering  a  transaction  unless  a  rendezvous  occurred. 

Proof.  By  inspection  of  the  alternative  algorithm,  the  process  only 
returns  to  the  Running  state  when  either:  (a)  Pt(Tr)  signals  PJ  or  (b)  after 
P,( Tr )  receives  a  signal  from  P,.  In  either  case,  P,(Tr)  rendezvoused 
with  Pj.  | 

Lemma  7.  A  process  P,  cannot  remain  blocked  on  a  Lock 
operation  in  the  alternative  algorithm  for  an  unbounded  amount  of  time. 

Proof.  The  only  Lock  operation  performed  by  the  algorithm  is  to 
serialize  accesses  to  Alt  List.  However,  no  unbounded  loop  or  blocking 
primitive  is  executed  before  the  corresponding  Unlock  is  performed.  No 
process  will  remain  blocked  attempting  to  obtain  a  lock  for  an  unbounded 
amount  of  time  because  every  lock  will  eventually  by  unlocked,  and  the 
Lock  primitive  is  assumed  to  be  fair.  | 

Lemma  8.  Suppose  P,e  GuardListj(Ts)  and  PjE  Guard  List  ,(Tr), 
and  their  respective  I/O  guards  are  compatible.  P,  and  Py  cannot  both 
block  for  an  unbounded  amount  of  time  in  the  Waitung  state  during 
transactions  Tr  and  Ts,  respectively. 

Proof.  Suppose  both  P,  and  P,  block  in  the  Waiting  state  on  T,  and 
T„  respectively.  Because  P,  reached  the  Waiting  state,  it  must  be  the  case 
that  the  last  time  P,  scanned  the  state  of  Py  before  P,  entered  the  Waiting 
state,  State j  was  either  (1)  Running,  (2)  Sleeping,  or  (3)  Waiting  but  P, 
failed  to  commit  to  Pj.  Consider  the  third  case.  P(  must  have  been  in  a 
transaction  preceding  Ts  for  this  case  to  apply  because  if  Pj  had  been  in 
Ts ,  Pj  would  have  rendezvoused  with  some  other  process  and  completed 
T„  contradicting  our  initial  assumption  that  Pj{Ts)  blocked  in  the 
Waiting  state  for  an  unbounded  amount  of  time.  Therefore,  if  case  (3) 
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applies,  Pj  must  have  been  in  a  transaction  previous  to  Ts  when  P, 
observed  it  to  be  in  the  Waiting  state. 

Similarly,  Pj  also  reached  the  Waiting  state,  so  P,  must  have  been  in 
the  Running,  Sleeping,  and  Waiting  state  for  a  previous  transaction  the 
last  time  P,  scanned  P,  before  P,  entered  the  Waiting  state.  P,  and  Pj  could 
not  have  both  scanned  each  other  at  the  same  instant  because  each  would 
have  found  each  other  in  the  Alt  state.  Without  loss  of  generality,  let  us 
assume  P,  scanned  P;  first.  P,{Tr)  was  in  the  Alt  state  when  it  scanned  Pr 
and  because  it  did  not  rendezvous  or  abort  (the  latter  would  require  Pj  to 
be  scanned  again,  making  this  not  the  last  time  P,  scanned  P;),  P,  must 
have  remained  in  the  Alt  state  until  it  changed  to  the  Waiting  state  and 
blocked  indefinitely.  Therefore,  when  P,  later  scanned  P,  for  the  last  time, 
Pj  must  have  seen  P,  in  either  the  Alt  or  the  Waiting  state  for  transaction 
Tr.  However,  this  contradicts  the  fact  that  P,  saw  P,  in  the  Running, 
SLEEFiNG,  or  Waiting  state  for  a  previous  transaction.  Therefore,  the 
original  hypothesis  that  P,  and  Pj  both  entered  the  Waiting  state  must  be 
false.  | 

The  proof  of  Lemma  8  relies  on  the  fact  that  processes  leaving  the 
Sleeping  state  abort  and  retry  the  alternative  operation  rather  than  simply 
resume  it.  If  resumption  were  used,  a  race  condition  would  exist  whereby  P, 
and  Pj  might  both  enter  the  Waiting  state. 

Lemma  9.  The  TryAltemative  procedure  cannot  return  Failed  an 
unbounded  number  of  times  during  a  single  transaction  Tr  in  some 
process  P,  . 

Proof.  Suppose  the  TryAltemative  procedure  fails  an  unbounded 
number  of  times.  TryAltemative  returns  Failed  if  and  only  if  P,  scans 
another  process  P,  and  finds  P,  is  also  in  the  Alt  state,  and  TransID j  < 
TransID,.  The  number  of  guards  in  GuardList  is  finite,  so  these  conditions 
persist  in  (some)  Pj  an  unbounded  amount  of  time.  Because  there  are  only 
a  finite  number  of  transactions  with  IDs  less  than  TransID ,,  this  condition 
must  persist  within  a  single  transaction  Ts.  P,  will  not  retry  until  P,  leaves 
the  Alt  state,  so  P;  must  also  abort  (changing  to  the  Sleeping  state)  and 
retry  (changing  back  to  Alt)  an  unbounded  number  of  times. 

Similarly,  Py  will  only  continue  to  abort  if  some  other  process  Pk  exists 
which  also  fails  within  a  single  transaction  an  unbounded  number  of  times, 
and  TransIDk  <  TransID ,.  Because  the  number  of  processes  is  bounded, 
a  cycle  of  processes  must  exist  such  that  TransID,  >  TransID j  > 
TransID k  >  ■  ■  ■  >  TransID ,,  which  of  course,  cannot  occur.  Therefore,  a 
process  cannot  fail  the  TryAltemative  procedure  an  unbounded  number  of 
times.  | 


Construct  in  CSP 


237 


Lemma  10.  A  process  P,  cannot  remain  continuously  in  the  Alt 
state  during  a  single  transaction  Tr  for  an  unbounded  amount  of  time. 

Proof.  Because  GuardList  is  bounded  in  length,  we  must  show  that 
P,  does  not  spend  an  unlimited  amount  of  time  scanning  a  particular 
guard.  This  can  only  occur  if  some  other  process  P,  exists  such  that  ( 1 )  P, 
continually  samples  P,  while  State t  is  Alt,  (2)  Py  remains  in  the  same 
transaction  with  ID  TransIDj .  and  (3)  TransID,  <  TranslDj. 

According  to  the  previous  lemma,  Pj  cannot  abort  and  retry  the  alter¬ 
native  operation  within  a  single  transaction  an  unbounded  number  of 
times.  Therefore,  Pf  must  also  remain  continuously  locked  in  the  Alt  state 
an  unbounded  amount  of  time. 

An  argument  similar  to  that  used  in  the  previous  lemma  can  now  be 
used.  Pf  will  only  remain  continuously  in  the  Alt  state  an  unbounded 
amount  of  time  if  some  other  process  Pk  is  in  P- s  GuardList ,  TransID ;  < 
TransID k,  and  Pk  remains  continuously  in  the  Alt  state  an  unbounded 
amount  of  time.  A  cycle  of  processes  must  exist  such  that  each  is  waiting 
for  the  next  process  in  the  cycle  to  leave  the  Alt  state.  This  would  require 
that  TransID i  <  TransIDj  <  TransID k  <  ■  ■  ■  <  Transit D„  so  no  such  cycle 
can  exist.  | 

Lemma  11.  A  process  P,  cannot  remain  continuously  in  the 
Sleeping  state  during  a  single  transaction  T,  for  an  unbounded  amount  of 
time. 

Proof.  P,  can  only  remain  in  the  Sleeping  state  an  unbounded 
amount  of  time  waiting  for  some  process  P,  if  ( 1 )  P,  continually  samples  P, 
while  State j  is  Alt,  and  (2)  P,  remains  in  the  same  transaction  Ts. 

These  conditions  can  only  persist  if  either  P,  aborts  and  retries  the 
transaction  Ts  an  unbounded  number  of  times,  or  P,  remains  continuously 
in  the  Alt  state  for  an  unbounded  amount  of  time.  Lemmas  9  and  10 
proved  that  neither  is  possible,  so  P,  cannot  remain  in  the  Sleeping  state 
an  unbounded  amount  of  time.  | 

Lemma  12.  For  each  alternative  operation  initiated  by  P,,  P,  even¬ 
tually  either  rendezvous  with  some  other  process  P,  and  returns  to  the 
Running  state  or  moves  to  the  Waiting  state. 

Proof.  The  only  way  a  process  can  not  reach  the  Waiting  state  or 
rendezvous  is  to  remain  continually  in  the  Alt  state,  remain  continually  in 
the  Sleeping  state,  or  switch  back  and  forth  between  Alt  and  Sleeping  an 
unbounded  number  of  times.  The  latter  case  implies  Try  Alternative  fails  an 
unbounded  number  of  times  within  a  single  transaction.  None  of  these  is 
possible  according  to  Lemmas  9-11.  | 
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Theorem  3  (Liveness).  Suppose  two  processes  P,  and  P,  each 
initiate  an  alternative  operation  and  PjeGuardListj(Tr)  and  P,e 
GuardListj(  Ts)  and  their  communication  requests  are  compatible.  If  neither 
P,  nor  Pj  rendezvous  with  another  process  during  their  respective  trans¬ 
actions,  /*,  and  Pj  will  eventually  rendezvous  with  each  other  during  T,  and 
Ts,  respectively. 

Proof.  According  to  Lemma  12,  P,  and  Ps  must  each  eventually 
either  rendezvous  or  enter  the  Waiting  state.  They  both  cannot  enter  the 
Waiting  state  according  to  Lemma  8.  Therefore,  at  least  one  of  the  two 
processes,  say  /*,,  must  rendezvous.  By  assumption,  P,  cannot  rendezvous 
with  any  process  other  than  Pn  so  P,  must  rendezvous  with  Pj.  By 
Theorem  2,  Pt  must  also  rendezvous  with  P,.  Therefore,  P,  and  Pt  must 
eventually  rendezvous  with  each  other.  | 

7.  FAIRNESS 

One  issue  regarding  the  alternative  construct  that  has  received  con¬ 
siderable  attention  is  fairness.  In  particular,  two  types  of  fairness,  weak  and 
strong  fairness,  have  been  defined  in  Refs.  20  and  22.  We  call  an  implemen¬ 
tation  of  the  alternative  construct  weakly  fair  if  it  can  be  guaranteed  that 
during  the  infinitely  repetitive  execution  of  an  alternative  command,  a 
guard  that  remains  continuously  available  (i.e.,  enabled  and  the  neighboring 
process  is  ready  to  communicate)  will  eventually  rendezvous.  An 
implementation  is  said  to  be  strongly  fair  if  the  implementation  guarantees 
that  any  guard  which  is  available  infinitely  often  (though  not  necessarily 
continuously  as  is  the  case  in  weak  fairness)  will  eventually  rendezvous. 

The  algorithm  shown  in  Figs.  2-4  is  not  fair  in  either  the  weak  or 
strong  sense.  However,  weak  fairness  can  be  achieved  by  modifying  the 
algorithm  so  that  the  order  in  which  the  Try  Alternative  procedure  scans 
guards,  which  implies  a  certain  prioritization  of  the  guards,  varies  from  one 
call  to  the  next  so  that  each  guard  is  eventually  scanned  first.  More 
precisely,  we  modify  the  algorithm  as  follows: 

•  Define  a  distinct  integer  variable  for  each  alternative  construct  in  a 
given  CSP  program.  These  variables  could  be  defined  by  the  com¬ 
piler.  Associate  with  the  Arth  alternative  construct  in  process  P,  the 
variable  Altik.  Initially  set  to  0,  this  variable  is  incremented  each 
time  this  particular  alternative  construct  is  invoked.  It  therefore 
indicates  the  number  of  times  Pt  has  invoked  the  corresponding 
alternative  construct. 

•  The  FOR  loop  in  the  TryA/ternative  procedure  is  modified  so  that 
it  begins  scanning  guard  (Alti  k  mod  n)+  1  rather  than  the  first 
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guard,  where  n  is  the  number  of  guards  in  the  alternative  construct. 
The  FOR  loop  is  also  modified  to  skip  disable  guards.  If  executes 
up  to  n  iterations  as  before.  The  index  variable  of  the  FOR  loop 
“wraps  around”  to  1  after  scanning  the  nth  guard. 

The  modified  algorithm  is  referred  to  as  the  Fair  Algorithm,  and  is 
assumed  in  the  discussion  which  follows. 

Theorem  4  (Fairness).  Let  P,  be  blocked  on  an  alternative 
operation  (i.e.,  P,  is  in  the  Waiting  state)  in  which  some  proces  P,  is  listed 
in  some  enabled  guard.  Further,  let  us  assume  P,  does  not  become 
unblocked  through  a  rendezvous  with  any  process  other  than  Pr  Consider 
an  alternative  construct  A  in  Pt  that  has  been  executed  u  times  and  con¬ 
tains  n  guards,  one  of  which  (g,,)  contains  a  compatible  communication 
with  P,.  If  Pi  now  executes  A  at  least  n  more  times  and  g,,  is  enabled  on 
each  of  these  n  invocations  of  A,  then  P,  and  P,  will  rendezvous  before  the 
(«  +  n)th  execution  of  A  completes. 

Proof.  The  theorem  can  be  proven  by  contradiction.  Suppose  P,  does 
not  rendezvous  with  P,  before  the  (u  +  n)th  execution  of  A.  For  this  to  hap¬ 
pen,  Pi  must  continually  be  rendezvousing  with  some  other  process! es) 
before  it  scans  P,  because  the  moment  it  scans  P„  it  will  see  that  P,  is  in 
the  Waiting  state  and  rendezvous  with  P,.  However,  the  Fair  Algorithm 
guarantees  that  within  n  executions  of  A,  g,.  will  become  the  first  guard 
that  is  scanned.  When  g,.  is  scanned  first,  no  other  process  can  rendezvous 
with  Pt  before  P )  scans  P„  so  a  rendezvous  between  P,  and  P,  must  take 
place.  | 

The  following  corollary  follows  immediately  from  this  theorem: 

Corollary  1 .  In  an  infinitely  repetitive  execution  of  an  alternative 
construct,  a  guard  cannot  remain  continually  available  for  an  unbounded 
amount  of  time  without  eventually  rendezvousing. 

This  shows  that  the  Fair  Algorithm  is  weakly  fair.  It  demonstrates,  for 
instance,  that  a  process  waiting  to  be  served  by  another  process  cannot  be 
continuously  denied  service  for  an  unbounded  amount  of  time.  The  Fair 
Algorithm  is  not  strongly  fair,  however.  Modification  of  this  algorithm  to 
one  which  is  strongly  fair  is  an  open  question.  None  of  the  alternative 
algorithms  that  have  been  developed  thus  far  (based  on  message-passing 
architectures)  is  strongly  fair. 

8.  CONCLUSIONS 

We  have  presented  an  algorithm  that  implements  the  generalized  alter¬ 
native  construct  in  CSP.  Unlike  previous  algorithms,  it  is  based  on  a 
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shared  memory  architecture.  It  has  been  shown  that  the  algorithm  main¬ 
tains  the  safety  and  liveness  properties  required  by  any  correct  implemen¬ 
tation.  Extensions  to  the  algorithm  that  allow  processes  to  terminate  and 
guarantee  weak  fairness  were  also  presented.  An  implementation,  written  in 
C,  has  been  developed  for  a  18-processor  BBN  Butterfly  parallel  processor. 
Empirical  performance  evaluation  of  this  implementation  is  in  progress. 
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